Skip to content

Sport Mode, part 2/5: RileyLinkKit — watchOS framework targets - #18

Draft
ps2 wants to merge 3 commits into
next-devfrom
sportmode/rileylink-upstream
Draft

Sport Mode, part 2/5: RileyLinkKit — watchOS framework targets#18
ps2 wants to merge 3 commits into
next-devfrom
sportmode/rileylink-upstream

Conversation

@ps2

@ps2 ps2 commented Sep 7, 2026

Copy link
Copy Markdown

What this is

The RileyLinkKit slice of Jeremy Barnum's Sport Mode line (standalone watch). Part 2 of a
bottom-up landing: LoopKit (ps2#612) → RileyLinkKit / G7SensorKit → OmnipodKit → Loop →
workspace pin bump.

Draft: design review wanted before this goes near next-dev.

Three commits, rebased onto current next-dev (8ba261c). Cherry-picks were clean.

The changes

  1. RileyLinkBLEKit-watchOS and RileyLinkKit-watchOS framework targets — new targets only;
    no existing target's membership or settings change.
  2. #if os(iOS) guards around CoreBluetooth state restoration in
    RileyLinkBluetoothDeviceProvider. watchOS has no state restoration, and the watch host owns
    reconnect policy.
  3. Deployment target 10.6 on RileyLinkKit-watchOS, to match LoopKit.

Net effect on iOS: nothing. The only source file touched is
RileyLinkBluetoothDeviceProvider.swift, and only inside #if os(iOS) / #else.

The rebase landed on top of #16 (autoConnectIDs thread safety), and the two compose cleanly —
git auto-merged them, and the resulting file keeps the Locked<Set<String>> treatment with the
platform guards around the restoration option.

A gap worth deciding on

Unlike G7SensorKit, these targets ship no shared scheme, so they cannot be built from the
command line or by CI. They also cannot build standalone (-project RileyLinkKit.xcodeproj -target RileyLinkKit-watchOS -sdk watchsimulator fails with unable to resolve module dependency: 'LoopKit') because LoopKit comes from the workspace.

I verified them by generating shared schemes temporarily and building through
LoopWorkspace.xcworkspaceboth targets: BUILD SUCCEEDED against generic/platform=watchOS Simulator. Those temporary schemes are deliberately not in this branch.

Say the word and I'll add proper shared schemes so these are CI-buildable; I left them out rather
than expand the diff beyond Jeremy's commits without asking.

Verification

  • xcodebuild -workspace LoopWorkspace.xcworkspace -scheme LoopWorkspace against stock
    next-dev
    (stock LoopKit, this branch + the G7 branch swapped in): BUILD SUCCEEDED.
  • Both new watchOS targets build (via temporary schemes, as above).
  • Content diff against Jeremy's RileyLinkKit tip is exactly the intervening next-dev commit —
    his work carried forward, nothing added or lost.

Jeremy Barnum and others added 3 commits September 7, 2026 12:51
Mirrors the LoopKit-watchOS pattern: same product names, SDKROOT=watchos,
device family 4, APPLICATION_EXTENSION_API_ONLY, deployment 8.0. Same source
lists as the iOS targets; RileyLinkKit-watchOS depends on RileyLinkBLEKit-watchOS
and links LoopKit (watchOS product via workspace implicit dependencies).
Needed because OmnipodKit's unified OmniPumpManager subclasses
RileyLinkPumpManager.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two sites: CBCentralManagerOptionRestoreIdentifierKey in the central init
(watchOS: options nil) and the willRestoreState delegate method. No iOS
behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant